Drafts for published metadata

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Drafts for published metadata

Maria Arias de Reyna-2
Hi,

We are working on a proposal to have a basic versioning on published
metadata. We are working over some design we made two years ago in
Bolsena with Jesse's colaboration, but as we know that not everyone
participated, we thought it might be useful to share it here.

The idea is simple:

When a published metadata is edited, a new copy is saved on both the
database and the index marked with the draft flag. This way a user
with enough privileges can view, search and edit published metadata
without modifying what the rest of the users see about this metadata.
This is specially useful for long editings (that last more than one
session) or edits that need some kind of review from several users
before getting published.

This draft is blocked while a user is editing it to prevent other
concurrent editing with other users. This block is released either
when the editor is closed or after a timeout of inactivity.

Once the draft copy is published, the original published metadata gets
replaced with the draft copy and the draft is removed from the system.

We will probably extend the blocking system to the normal metadata
editing, as right now it can be very confusing if more than one user
edit the same metadata at the same time.

Drafts will be saved on a different table on the database, so we can
keep a unique identifier by uuid on the metadata table. The lucene
index will be the same, just adding the "draft" flag.

All this draft thing will be enabled by configuration, so you can keep
the current implementation if you want. Unless there is consense that
it should be defaulted because it doesn't make sense what we have now.
Should we make the locking over editing also configurable?

So this is the time for brainstorm. Any ideas? Any parallel
implementation? Paul remembers Simon saying something about using svn
for this, but I am not sure what was the idea and he didn't remember
it completely, so if you remember something about it, this is the time
and place.

Kind regards,

María Arias de Reyna Domínguez


Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664



Please consider the environment before printing this email.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

Francois Prunayre
Hi Maria,

2015-12-01 12:44 GMT+01:00 Maria Arias de Reyna <[hidden email]>:
Hi,

We are working on a proposal to have a basic versioning on published
metadata. We are working over some design we made two years ago in
Bolsena with Jesse's colaboration, but as we know that not everyone
participated, we thought it might be useful to share it here.

The idea is simple:

When a published metadata is edited, a new copy is saved on both the
database and the index marked with the draft flag. This way a user
with enough privileges can view, search and edit published metadata
without modifying what the rest of the users see about this metadata.
This is specially useful for long editings (that last more than one
session) or edits that need some kind of review from several users
before getting published.

This draft is blocked while a user is editing it to prevent other
concurrent editing with other users. This block is released either
when the editor is closed or after a timeout of inactivity.

Once the draft copy is published, the original published metadata gets
replaced with the draft copy and the draft is removed from the system.

We will probably extend the blocking system to the normal metadata
editing, as right now it can be very confusing if more than one user
edit the same metadata at the same time.

Drafts will be saved on a different table on the database, so we can
keep a unique identifier by uuid on the metadata table. The lucene
index will be the same, just adding the "draft" flag.

All this draft thing will be enabled by configuration, so you can keep
the current implementation if you want.

+1
 
Unless there is consense that
it should be defaulted because it doesn't make sense what we have now.
Should we make the locking over editing also configurable?

Maybe not, because currently users get an exception in that case so the lock will avoid that case.

 
So this is the time for brainstorm. Any ideas? Any parallel
implementation?

Not on my side.

Cheers.

Francois

 
Paul remembers Simon saying something about using svn
for this, but I am not sure what was the idea and he didn't remember
it completely, so if you remember something about it, this is the time
and place.

Kind regards,

María Arias de Reyna Domínguez


Veenderweg 13
6721 WD Bennekom
The Netherlands
T: <a href="tel:%2B31%20%280%29318%20416664" value="+31318416664">+31 (0)318 416664



Please consider the environment before printing this email.


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

Florent gravin-2
+1

Will this get into conflicts with metadata status management ?

On Tue, Dec 1, 2015 at 1:34 PM, Francois Prunayre <[hidden email]> wrote:
Hi Maria,

2015-12-01 12:44 GMT+01:00 Maria Arias de Reyna <[hidden email]>:
Hi,

We are working on a proposal to have a basic versioning on published
metadata. We are working over some design we made two years ago in
Bolsena with Jesse's colaboration, but as we know that not everyone
participated, we thought it might be useful to share it here.

The idea is simple:

When a published metadata is edited, a new copy is saved on both the
database and the index marked with the draft flag. This way a user
with enough privileges can view, search and edit published metadata
without modifying what the rest of the users see about this metadata.
This is specially useful for long editings (that last more than one
session) or edits that need some kind of review from several users
before getting published.

This draft is blocked while a user is editing it to prevent other
concurrent editing with other users. This block is released either
when the editor is closed or after a timeout of inactivity.

Once the draft copy is published, the original published metadata gets
replaced with the draft copy and the draft is removed from the system.

We will probably extend the blocking system to the normal metadata
editing, as right now it can be very confusing if more than one user
edit the same metadata at the same time.

Drafts will be saved on a different table on the database, so we can
keep a unique identifier by uuid on the metadata table. The lucene
index will be the same, just adding the "draft" flag.

All this draft thing will be enabled by configuration, so you can keep
the current implementation if you want.

+1
 
Unless there is consense that
it should be defaulted because it doesn't make sense what we have now.
Should we make the locking over editing also configurable?

Maybe not, because currently users get an exception in that case so the lock will avoid that case.

 
So this is the time for brainstorm. Any ideas? Any parallel
implementation?

Not on my side.

Cheers.

Francois

 
Paul remembers Simon saying something about using svn
for this, but I am not sure what was the idea and he didn't remember
it completely, so if you remember something about it, this is the time
and place.

Kind regards,

María Arias de Reyna Domínguez


Veenderweg 13
6721 WD Bennekom
The Netherlands
T: <a href="tel:%2B31%20%280%29318%20416664" value="+31318416664" target="_blank">+31 (0)318 416664



Please consider the environment before printing this email.


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork



--
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Florent Gravin
0479444492

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

delawen
Hi,

The idea is that it doesn't conflict. The draft metadata will have a
status draft and the published as status published. We can either
ignore the status of the draft or just add it so we know that there is
simultaneously a drafted and a published metadata with the same uuid.

On Tue, Dec 1, 2015 at 3:12 PM, Florent Gravin
<[hidden email]> wrote:

> +1
>
> Will this get into conflicts with metadata status management ?
>
> On Tue, Dec 1, 2015 at 1:34 PM, Francois Prunayre <[hidden email]>
> wrote:
>>
>> Hi Maria,
>>
>> 2015-12-01 12:44 GMT+01:00 Maria Arias de Reyna <[hidden email]>:
>>>
>>> Hi,
>>>
>>> We are working on a proposal to have a basic versioning on published
>>> metadata. We are working over some design we made two years ago in
>>> Bolsena with Jesse's colaboration, but as we know that not everyone
>>> participated, we thought it might be useful to share it here.
>>>
>>> The idea is simple:
>>>
>>> When a published metadata is edited, a new copy is saved on both the
>>> database and the index marked with the draft flag. This way a user
>>> with enough privileges can view, search and edit published metadata
>>> without modifying what the rest of the users see about this metadata.
>>> This is specially useful for long editings (that last more than one
>>> session) or edits that need some kind of review from several users
>>> before getting published.
>>>
>>> This draft is blocked while a user is editing it to prevent other
>>> concurrent editing with other users. This block is released either
>>> when the editor is closed or after a timeout of inactivity.
>>>
>>> Once the draft copy is published, the original published metadata gets
>>> replaced with the draft copy and the draft is removed from the system.
>>>
>>> We will probably extend the blocking system to the normal metadata
>>> editing, as right now it can be very confusing if more than one user
>>> edit the same metadata at the same time.
>>>
>>> Drafts will be saved on a different table on the database, so we can
>>> keep a unique identifier by uuid on the metadata table. The lucene
>>> index will be the same, just adding the "draft" flag.
>>>
>>> All this draft thing will be enabled by configuration, so you can keep
>>> the current implementation if you want.
>>
>>
>> +1
>>
>>>
>>> Unless there is consense that
>>> it should be defaulted because it doesn't make sense what we have now.
>>> Should we make the locking over editing also configurable?
>>
>>
>> Maybe not, because currently users get an exception in that case so the
>> lock will avoid that case.
>>
>>
>>>
>>> So this is the time for brainstorm. Any ideas? Any parallel
>>> implementation?
>>
>>
>> Not on my side.
>>
>> Cheers.
>>
>> Francois
>>
>>
>>>
>>> Paul remembers Simon saying something about using svn
>>> for this, but I am not sure what was the idea and he didn't remember
>>> it completely, so if you remember something about it, this is the time
>>> and place.
>>>
>>> Kind regards,
>>>
>>> María Arias de Reyna Domínguez
>>>
>>>
>>> Veenderweg 13
>>> 6721 WD Bennekom
>>> The Netherlands
>>> T: +31 (0)318 416664
>>>
>>>
>>>
>>> Please consider the environment before printing this email.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Go from Idea to Many App Stores Faster with Intel(R) XDK
>> Give your users amazing mobile app experiences with Intel(R) XDK.
>> Use one codebase in this all-in-one HTML5 development environment.
>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
>> OSs.
>> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>> _______________________________________________
>> GeoNetwork-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
>> GeoNetwork OpenSource is maintained at
>> http://sourceforge.net/projects/geonetwork
>
>
>
>
> --
> camptocamp
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> Florent Gravin
> 0479444492
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> GeoNetwork-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> GeoNetwork OpenSource is maintained at
> http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

Paul van Genuchten
In reply to this post by Maria Arias de Reyna-2
Hi, as Maria indicated I remember from last years Bolsena discussion
that Simon suggested to use svn (and/or git) for metadata workflow.

As I remember the idea was as soon as a user starts an editing session,
the update is stored as a branch in svn/github. When the metadata is
published the change-branch is merged with master.

Recent developments around workflow added an aspect of adding the
changed metadata to the index, so users that created metadata, which is
not published yet, are also able to find their metadata using q
services. But this feature is not directly related to the type of
storage we select. I guess the index can also index all latest versions
in all git/svn branches.

Certainly using git/svn will be a bigger development as the one Maria
suggested, and the Maria approach may be a first step to introducing
proper workflow. Because it includes quite a lot of UI challenges also:
- new metadata statuses are introduced that need to be visualised in the
UI; draft-created, draft-modified, draft-removed
- new screen elements for request for publication (from/to/comment),
list of pending requests/review tasks, review screen (view changes?)
with option to deny (from/to/comment)
- notification system to send review requests

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

Jose Garcia
Hi Paul

Apologies as I don't remember about the git/svn discussion in Bolsena for the workflow. The developments for the draft metadata were done for 2.8 version for AGIV in Belgium and migrated/improved to 2.10 for Environment Canada. The scope for this work is to migrate all these developments to GN 3.0 and refactor it properly. The actual feature works as described Maria in previous mails, using Lucene and database.

I think is good to discuss any improvements or alternative storage if we think this can be better. But related to your comment:

As I remember the idea was as soon as a user starts an editing session, the update is stored as a branch in svn/github. When the metadata is published the change-branch is merged with master.

I think that can solve the storage, but at least actually searches are done against the lucene index. In any case I guess Simon can provide some feedback about this stuff.

Regards,
Jose García


On Wed, Dec 2, 2015 at 9:10 AM, Paul van Genuchten <[hidden email]> wrote:
Hi, as Maria indicated I remember from last years Bolsena discussion
that Simon suggested to use svn (and/or git) for metadata workflow.

As I remember the idea was as soon as a user starts an editing session,
the update is stored as a branch in svn/github. When the metadata is
published the change-branch is merged with master.

Recent developments around workflow added an aspect of adding the
changed metadata to the index, so users that created metadata, which is
not published yet, are also able to find their metadata using q
services. But this feature is not directly related to the type of
storage we select. I guess the index can also index all latest versions
in all git/svn branches.

Certainly using git/svn will be a bigger development as the one Maria
suggested, and the Maria approach may be a first step to introducing
proper workflow. Because it includes quite a lot of UI challenges also:
- new metadata statuses are introduced that need to be visualised in the
UI; draft-created, draft-modified, draft-removed
- new screen elements for request for publication (from/to/comment),
list of pending requests/review tasks, review screen (view changes?)
with option to deny (from/to/comment)
- notification system to send review requests

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork



--
Vriendelijke groeten / Kind regards,

Jose García


Veenderweg 13
6721 WD Bennekom
The Netherlands
T: <a href="tel:+31318416664" style="font-family:Helvetica,Arial,sans-serif" target="_blank">+31 (0)318 416664

  

Please consider the environment before printing this email.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

SimonPigot
In reply to this post by Paul van Genuchten
Hi Paul,

The svn stuff wasn't just a suggestion - certainly in 2.10.x it is actually implemented. I haven't checked 3.x.x to see whether it works as originally implemented, but the core (at least) appears to have been ported. The original proposal is doco'd at http://trac.osgeo.org/geonetwork/wiki/metadatachanges

At the time the proposal was written and after the work was done, the linkage between database commits and subversion repo commits became more difficult to manage - this would need to be reviewed in the light of very large changes that have been made to the way in which persistence is handled in 3.x.x. However, if we went this way it would provide a much more powerful facility than the other proposal (especially as it captures changes to metadata attributes eg. categories, status, permissions etc). No need to implement the whole history mechanism in the U/I to begin with, it would probably be suitable to just implement the functions required to support editing versions.

Cheers,
Simon
________________________________________
From: Paul van Genuchten [[hidden email]]
Sent: Wednesday, 2 December 2015 7:10 PM
To: [hidden email]; Pigot, Simon (O&A, Hobart)
Subject: Re: Drafts for published metadata

Hi, as Maria indicated I remember from last years Bolsena discussion
that Simon suggested to use svn (and/or git) for metadata workflow.

As I remember the idea was as soon as a user starts an editing session,
the update is stored as a branch in svn/github. When the metadata is
published the change-branch is merged with master.

Recent developments around workflow added an aspect of adding the
changed metadata to the index, so users that created metadata, which is
not published yet, are also able to find their metadata using q
services. But this feature is not directly related to the type of
storage we select. I guess the index can also index all latest versions
in all git/svn branches.

Certainly using git/svn will be a bigger development as the one Maria
suggested, and the Maria approach may be a first step to introducing
proper workflow. Because it includes quite a lot of UI challenges also:
- new metadata statuses are introduced that need to be visualised in the
UI; draft-created, draft-modified, draft-removed
- new screen elements for request for publication (from/to/comment),
list of pending requests/review tasks, review screen (view changes?)
with option to deny (from/to/comment)
- notification system to send review requests

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

delawen
Hi,

Maybe we can implement both (or add it later the repository thing)?

The main issue right now is that it cannot be handled only in the
repository. The lucene index and the database have to know about this
branch so it can be edited and shown on the metadata view.

I think it is a good idea to have branches (and move from svn to git
on the metadata data), but I see it as an addon, specially if we are
not sure if it still works. Did we ever had some kind of gui tool to
view the changes?

Regards,
María.

On Wed, Dec 2, 2015 at 10:00 AM,  <[hidden email]> wrote:
> Hi Paul,
>
> The svn stuff wasn't just a suggestion - certainly in 2.10.x it is actually implemented. I haven't checked 3.x.x to see whether it works as originally implemented, but the core (at least) appears to have been ported. The original proposal is doco'd at http://trac.osgeo.org/geonetwork/wiki/metadatachanges
>
> At the time the proposal was written and after the work was done, the linkage between database commits and subversion repo commits became more difficult to manage - this would need to be reviewed in the light of very large changes that have been made to the way in which persistence is handled in 3.x.x. However, if we went this way it would provide a much more powerful facility than the other proposal (especially as it captures changes to metadata attributes eg. categories, status, permissions etc). No need to implement the whole history mechanism in the U/I to begin with, it would probably be suitable to just implement the functions required to support editing versions.
>
> Cheers,
> Simon

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

Paul van Genuchten
In reply to this post by SimonPigot
Hi Simon, yes I am aware of the current SVN implementation. However I
remembered you suggested at some point to extend this mechanism to also
include a mechanism for metadata workflow, or did you mean the current
implementation does facilitate workflow, in a sense that, because you
have a history, you can always revert to previous versions, which can be
considered workflow.

Our suggestion is to introduce workflow in a way that metadata is
create/updated in a non-public location, not overwriting anything that
is published yet. And as soon as a reviewer 'allows' the create/modify
the published vesion is replaced.

In SVN this could be implemented using branches which are committed to
master/trunk as soon as a reviewer has "published" the record. The
database only has the metadata that is in master/trunk. The index may
have both trunk records and branch records, because editors should be
able to find records that they are currently working on.


Op 2-12-2015 om 10:00 schreef [hidden email]:

> Hi Paul,
>
> The svn stuff wasn't just a suggestion - certainly in 2.10.x it is actually implemented. I haven't checked 3.x.x to see whether it works as originally implemented, but the core (at least) appears to have been ported. The original proposal is doco'd at http://trac.osgeo.org/geonetwork/wiki/metadatachanges
>
> At the time the proposal was written and after the work was done, the linkage between database commits and subversion repo commits became more difficult to manage - this would need to be reviewed in the light of very large changes that have been made to the way in which persistence is handled in 3.x.x. However, if we went this way it would provide a much more powerful facility than the other proposal (especially as it captures changes to metadata attributes eg. categories, status, permissions etc). No need to implement the whole history mechanism in the U/I to begin with, it would probably be suitable to just implement the functions required to support editing versions.
>
> Cheers,
> Simon
> ________________________________________
> From: Paul van Genuchten [[hidden email]]
> Sent: Wednesday, 2 December 2015 7:10 PM
> To: [hidden email]; Pigot, Simon (O&A, Hobart)
> Subject: Re: Drafts for published metadata
>
> Hi, as Maria indicated I remember from last years Bolsena discussion
> that Simon suggested to use svn (and/or git) for metadata workflow.
>
> As I remember the idea was as soon as a user starts an editing session,
> the update is stored as a branch in svn/github. When the metadata is
> published the change-branch is merged with master.
>
> Recent developments around workflow added an aspect of adding the
> changed metadata to the index, so users that created metadata, which is
> not published yet, are also able to find their metadata using q
> services. But this feature is not directly related to the type of
> storage we select. I guess the index can also index all latest versions
> in all git/svn branches.
>
> Certainly using git/svn will be a bigger development as the one Maria
> suggested, and the Maria approach may be a first step to introducing
> proper workflow. Because it includes quite a lot of UI challenges also:
> - new metadata statuses are introduced that need to be visualised in the
> UI; draft-created, draft-modified, draft-removed
> - new screen elements for request for publication (from/to/comment),
> list of pending requests/review tasks, review screen (view changes?)
> with option to deny (from/to/comment)
> - notification system to send review requests
>


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

Paul van Genuchten
In reply to this post by delawen
Maria, Heikki developed a view-changes UI for Agiv, based on some
xml-div library. But these developments were never brought to master,
because the workflow-pull request that was a dependancy for these
developments was unfortunately never integrated.


Op 2-12-2015 om 10:08 schreef María Arias de Reyna:

> Hi,
>
> Maybe we can implement both (or add it later the repository thing)?
>
> The main issue right now is that it cannot be handled only in the
> repository. The lucene index and the database have to know about this
> branch so it can be edited and shown on the metadata view.
>
> I think it is a good idea to have branches (and move from svn to git
> on the metadata data), but I see it as an addon, specially if we are
> not sure if it still works. Did we ever had some kind of gui tool to
> view the changes?
>
> Regards,
> María.
>
> On Wed, Dec 2, 2015 at 10:00 AM,  <[hidden email]> wrote:
>> Hi Paul,
>>
>> The svn stuff wasn't just a suggestion - certainly in 2.10.x it is actually implemented. I haven't checked 3.x.x to see whether it works as originally implemented, but the core (at least) appears to have been ported. The original proposal is doco'd at http://trac.osgeo.org/geonetwork/wiki/metadatachanges
>>
>> At the time the proposal was written and after the work was done, the linkage between database commits and subversion repo commits became more difficult to manage - this would need to be reviewed in the light of very large changes that have been made to the way in which persistence is handled in 3.x.x. However, if we went this way it would provide a much more powerful facility than the other proposal (especially as it captures changes to metadata attributes eg. categories, status, permissions etc). No need to implement the whole history mechanism in the U/I to begin with, it would probably be suitable to just implement the functions required to support editing versions.
>>
>> Cheers,
>> Simon


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

SimonPigot
In reply to this post by delawen
Hi Maria,

If it doesn't work as implemented then we should fix it! :-) There is the facility to turn on version control in 3.x.x - its in the editor under settings. It doesn't seem to work in 3.x.x (at least for the H2 db) - throws an exception from somewhere within the spring transaction innards.

No gui tool in GN - we were relying on external repository viewers like viewvc.

On the surface at least, it seems the svn part could be replaced with jgit fairly easily.

Cheers,
Simon

________________________________________
From: María Arias de Reyna [[hidden email]]
Sent: Wednesday, 2 December 2015 8:08 PM
To: Pigot, Simon (O&A, Hobart)
Cc: Paul van Genuchten; Devel [hidden email]
Subject: Re: [GeoNetwork-devel] Drafts for published metadata

Hi,

Maybe we can implement both (or add it later the repository thing)?

The main issue right now is that it cannot be handled only in the
repository. The lucene index and the database have to know about this
branch so it can be edited and shown on the metadata view.

I think it is a good idea to have branches (and move from svn to git
on the metadata data), but I see it as an addon, specially if we are
not sure if it still works. Did we ever had some kind of gui tool to
view the changes?

Regards,
María.

On Wed, Dec 2, 2015 at 10:00 AM,  <[hidden email]> wrote:
> Hi Paul,
>
> The svn stuff wasn't just a suggestion - certainly in 2.10.x it is actually implemented. I haven't checked 3.x.x to see whether it works as originally implemented, but the core (at least) appears to have been ported. The original proposal is doco'd at http://trac.osgeo.org/geonetwork/wiki/metadatachanges
>
> At the time the proposal was written and after the work was done, the linkage between database commits and subversion repo commits became more difficult to manage - this would need to be reviewed in the light of very large changes that have been made to the way in which persistence is handled in 3.x.x. However, if we went this way it would provide a much more powerful facility than the other proposal (especially as it captures changes to metadata attributes eg. categories, status, permissions etc). No need to implement the whole history mechanism in the U/I to begin with, it would probably be suitable to just implement the functions required to support editing versions.
>
> Cheers,
> Simon

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

Maria Arias de Reyna-2
In reply to this post by Maria Arias de Reyna-2
Hi,

This is what we have right now:
https://docs.google.com/document/d/1fp1qnwlNOadOynonb3Y6BsMUb-jsYoPzfpLYKHaEzjg/edit?usp=sharing

It's not very detailed, but works for a proposal. We have omitted the
svn repository part because we will not have funding enough for it,
but we will add events so it will be easy to develop a repository
addon based on the changes on the metadata.


On Tue, Dec 1, 2015 at 12:44 PM, Maria Arias de Reyna
<[hidden email]> wrote:

> Hi,
>
> We are working on a proposal to have a basic versioning on published
> metadata. We are working over some design we made two years ago in
> Bolsena with Jesse's colaboration, but as we know that not everyone
> participated, we thought it might be useful to share it here.
>
> The idea is simple:
>
> When a published metadata is edited, a new copy is saved on both the
> database and the index marked with the draft flag. This way a user
> with enough privileges can view, search and edit published metadata
> without modifying what the rest of the users see about this metadata.
> This is specially useful for long editings (that last more than one
> session) or edits that need some kind of review from several users
> before getting published.
>
> This draft is blocked while a user is editing it to prevent other
> concurrent editing with other users. This block is released either
> when the editor is closed or after a timeout of inactivity.
>
> Once the draft copy is published, the original published metadata gets
> replaced with the draft copy and the draft is removed from the system.
>
> We will probably extend the blocking system to the normal metadata
> editing, as right now it can be very confusing if more than one user
> edit the same metadata at the same time.
>
> Drafts will be saved on a different table on the database, so we can
> keep a unique identifier by uuid on the metadata table. The lucene
> index will be the same, just adding the "draft" flag.
>
> All this draft thing will be enabled by configuration, so you can keep
> the current implementation if you want. Unless there is consense that
> it should be defaulted because it doesn't make sense what we have now.
> Should we make the locking over editing also configurable?
>
> So this is the time for brainstorm. Any ideas? Any parallel
> implementation? Paul remembers Simon saying something about using svn
> for this, but I am not sure what was the idea and he didn't remember
> it completely, so if you remember something about it, this is the time
> and place.
>
> Kind regards,
>
> María Arias de Reyna Domínguez
>
>
> Veenderweg 13
> 6721 WD Bennekom
> The Netherlands
> T: +31 (0)318 416664
>
>
>
> Please consider the environment before printing this email.



--
Kind regards,

María Arias de Reyna Domínguez


Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664



Please consider the environment before printing this email.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Drafts for published metadata

delawen
Hi,

As suggested yesterday, I moved the developments to the develop branch:

Feel free to test it.

There are two new implementations: 

 * Lock metadata editing: There is a new setting on the configuration that defines the timeout (minutes) of the lock (so it won't stay forever if the editor forgets to close the session). By default this is disabled (set as -1, which means: the lock will always be timed out). The lock is released when the edit session is cancelled or closed too.

If you are using an already deployed version, don't forget to add the new setting to the database:
INSERT INTO Settings (name, value, datatype, position, internal) 
VALUES ('metadata/lock', '-1', 1, 100003, 'n');

 * Draft metadata: When you edit a published metadata, instead of modify the published version, a ghost/draft metadata will be created where you can edit whatever you want for as long as you need. Once you want to publish the changes, just publish the drafted version and it will replace the already published metadata with your edited one.

I prefer not to disclose the exact steps to do things yet because if you are going to test, I want you to do blind tests. The steps I always do are fine, I want to know if other order or other steps cause failures.

Let me know if you find unexpected things.

Once I make sure it has no evident bugs, I will fix the tests. Last time I checked, it failed. So don't worry about that.

Regards,
María.


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork